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Abstract. Many languages and algebras have been proposed in recent 
years for the specification of authorization policies. For some proposals, 
such as XACML, the main motivation is to address real-world require- 
ments, typically by providing a complex policy language with somewhat 
informal evaluation methods; others try to provide a greater degree of 
formality - particularly with respect to policy evaluation - but support 
far fewer features. In short, there are very few proposals that combine 
a rich set of language features with a well-defined semantics, and even 
fewer that do this for authorization policies for attribute-based access 
control in open environments. In this paper, we decompose the problem 
of policy specification into two distinct sub-languages: the policy target 
language (PTL) for target specification, which determines when a pol- 
icy should be evaluated; and the policy composition language (PCL) for 
building more complex policies from existing ones. We define synta:x and 
semantics for two such languages and demonstrate that they can be both 
simple and expressive. PTaCL, the language obtained by combining the 
features of these two sub-languages, supports the specification of a wide 
range of policies. However, the power of PTaCL means that it is possi- 
ble to define policies that could produce unexpected results. We provide 
an analysis of how PTL should be restricted and how policies written 
in PCL should be evaluated to minimize the likelihood of undesirable 
results. 
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1 Introduction 

One of the fundamental security services in computer systems is access control, 
a mechanism for constraining the interaction between (authenticated) users and 
protected resources. Generally, access control is implemented by an authorization 



service, which inchides an authorization decision function (ADF) for deciding 
whether a user request to access a resource (an "access request") should be 
permitted or not. In its simplest form an authorization decision function either 
returns an allow or a deny decision. 

Many access control models and systems are policy-based, in the sense that 
a request for access to protected resources is evaluated with respect to a policy 
that defines which requests are authorized. Many languages have been proposed 
for the specification of authorization policies, perhaps the best known being 
XACML |3I7I13| . However, it is generally acknowledged that XACML suffers 
from having poorly defined and counterintuitive semantics |ll|12j . More formal 
approaches have provided well-defined semantics and typically use "policy oper- 
ators" to construct complex policies from simpler sub-policies |1I4I16) . However, 
such approaches tend to support fewer "features" than XACML. 

In a "closed" information system - one in which all authorized users are 
known to the system - it is possible to authenticate users of the system and 
to ascribe an identity to processes associated with those users. Hence, access 
control decisions and the policies that inform those decisions can be based on 
user identifiers. 

Increasingly, it is necessary to define authorization policies for "open" sys- 
tems, where we must make access control decisions based on user attributes, 
rather than identities. Hence, access request formats need to change from the 
user-centric subject-object-action triples of classical access control models [2|8j . 
although such request formats are still widely used in the specification of access 
control models and authorization policy languages |3l4l7ll3ll6j . 

An authorization policy is typically defined by a target, a set of child policies 
and a decision-combining algorithm. The target, either implicitly or explicitly, 
identifies a set of requests. The policy is said to be "applicable" if the access 
request belongs to (or "matches") the target. If a policy is applicable, then its 
child policies are evaluated and the results returned by those child policies are 
combined using the decision-combining algorithm. 

Informally, a policy may be regarded as a tree, in which the leaf nodes return 
a "conclusive" decision (allow or deny). If a request does not match the target 
of a leaf policy then the evaluation of that policy returns a "not applicable" 
decision. Hence, the set of possible decisions is 3-valued. 

However, it may be the case that it is not possible to evaluate request ap- 
plicability: perhaps the simplest case arises when the request is malformed. But 
once the request format is extended to accommodate attribute-based access con- 
trol, the problem of evaluating the applicability of a request becomes even more 
acute. In other words, the result of request applicability is not necessarily bi- 
nary: in particular, we must include a value that represents that some error has 
occurred while trying to evaluate request applicability. Naturally, extending the 
set of results that can be returned when evaluating request applicability means 
that we need to reconsider policy evaluation. 

We believe that existing proposals for authorization policy languages suffer 
from at least one of the following problems: 



— no support for attribute-based requests (and hence attribute-based autho- 
rization poHcies); 

— a lack of formahty in the definition of target and pohcy evaluation, leading 
to ambiguity about the meaning of policies; 

— a poor understanding of the way in which attribute-based requests, targets 
and policies interact. 

Our main objective is to define a policy language that addresses the same prob- 
lem space as XACML 3.0 [H] while retaining the formality of recent work on pol- 
icy algebras |1|4|5|6)16] . XACML (extensible access control markup language) 
is a standardized language: XACML 2.0 was ratified in 2005; XACML 3.0 will 
add support for attribute-based access control and policy administration. More 
specifically, our objectives are: 

— to define a request format that is appropriate for attribute-based authoriza- 
tion policies; 

— to define a syntax for specifying policy targets; 

— to formally define an evaluation method for those targets that is sufficiently 
robust to withstand deliberate attempts to exploit the greater freedom pro- 
vided by our request format; 

— to define a syntax for policies, which makes use of the policy target language; 

— to formally define an evaluation method for those policies that is able to 
handle errors in target evaluation gracefully and securely. 

In this paper, we develop two distinct languages for completely defining au- 
thorization policies. Roughly speaking, our goals are to combine support for 
the wide variety of policies that can be defined in more informal approaches 
such as XACML with the more formal semantics with which policy algebras 
are furnished. Our policy target language (PTL) provides a syntax for speci- 
fying policy targets, while our policy composition language (PCL), provides a 
language for combining policies (that is, constructing policy trees). Together, 
we call this PTaCL, read "p-tackle", to denote policy target and composition 
language. We also provide "authorization policy semantics" , which enable us to 
ascribe a meaning to a policy for a given request. That meaning is determined 
by the target semantics and the composition semantics. 

The main contribution of this work is therefore the definition of PTaCL, 
which, although far simpler syntactically than XACML 2.0 and 3.0, can express 
any desired target or policy, thanks to the functional completeness of PTL and 
PCL. We specify precisely how to evaluate any target and policy expressed in 
PTaCL, thus providing the basis for a low-level language into which XACML 
policies, for example, could be compiled and evaluated. Moreover, we identify 
the problem of attribute-hiding attacks, where a user deliberately suppresses 
attributes in order to gain favorable authorization decisions, and we propose 
different restrictions on the definition of a target in order to avoid such attacks. 
We note that such attacks are not peculiar to PTaCL; they are a potential 
problem for any attribute-based access control mechanism. We believe we are 
the first to identify and, therefore, propose mitigation strategies for, this type of 
attack. 



In the next section, we define our request format and illustrate some of the 
challenges introduced by attribute-based access control. Then, in Section [3j we 
define the syntax and evaluation method for targets. In Section |4j we define 
policy syntax and evaluation. In this section, we reflect on the problems that 
might arise because of the more flexible request format we use and explain how 
those problems inform the development of PTaCL. We also explain how PTL 
can be restricted to provide certain guarantees about the decisions returned by 
policy evaluation, thereby addressing the problem attribute-hiding attacks. We 
conclude the paper with a discussion of related work and some ideas for future 
work. 

2 Attribute-Based Requests 

The simplest authorization policy languages assume that an access request com- 
prises three identifiers: the requester, the resource to which access is requested, 
and the type of the requested interaction (such as read, write, etc), often known 
as subject, object and action, respectively. The authorization decision function 
(ADF) associated with a given language will take that request and an autho- 
rization policy as input and return a decision. For more complex languages, the 
ADF may require additional information, such as the roles or security groups 
associated with a user, in order to make a decision. These attributes may be 
"pushed" with the request or "pulled" from authoritative information sources 
(such as the policy information points in the XACML architecture) . The increas- 
ingly "open" nature of distributed computer systems, where the user population 
is not known in advance, requires authorization languages that are not based 
on user identities. For this reason, attribute-based access control (ABAC) and 
languages that support ABAC are expected to become increasingly important. 

PTaCL comprises two sub-languages: PTL for target specification and PCL 
for policy specification. Policies written in PTaCL are used to evaluate access 
requests that may contain arbitrary attributes associated with users, resources 
and actions. 

We model a request as a set of name-value pairs, where each name specifies 
an attribute and each value specifies a value for the corresponding attribute. 
In the simplest situation, for example, we might have attribute names such as 
subject, object and action, and a request might have the form 

{(subject, alice), (object, test.txt), (action, read)} . 

The above request is no different from the usual view of an access request as a 
subject-object-action triple. However, the request format described above is not 
limited to requests of this form and can be used to represent requests that do 
not contain identifiers for subjects, objects and actions. We could, for example, 
have a request of the form 



{(role, nurse), (object, test.txt), (action, read)} . 



An attribute name may appear multiple times in the request; the above request 
could include multiple role identifiers, for example. The use of some set of name- 
value pairs, rather than the fixed format subject-object-action triples (as used 
in XACML 2.0 and most other policy languages), means that we can specify 
targets and requests with greater freedom than is usually the case. However, the 
greater freedom with which requests can be specified also means that we have 
to take greater care in the specification of policies. 

As an example, we consider a simplified instance of the Chinese Wall policy, 
where a company A defines a policy to protect a set of confidential resources. 
Informally, this policy states that if a user is working for A, then she can ac- 
cess the (confidential) resource o, unless she is also working for B, the direct 
competitor of A, in which case the access is denied. We consider the following 
requests: 

ri = {(employer, A), (confidential, trite)} ; 

f2 = {(employer. A), (employer, B), (confidential, true)} ; 

r3 = {(confidential, /aZse)} ; 

r4 = {(confidential, trwe)} . 

Informally, an ABAC policy defines a set of atomic policies (or rules), where 
each atomic policy describes the subset of requests to which it applies - the 
policy's target - and the decision to take when it is applicable. When a request 
does not belong to the policy's target, then this policy is non- applicable, which 
has a different meaning from saying that the request is denied. The decisions 
returned by the evaluation of the atomic policies are then combined together 
using decision combination operators. 

For instance, the policy enforced by the company A should comprise two 
rules, the second of which is applicable to all requests and returns allow. The 
first rule is applicable if the request contains (confidential, true), and in this 
case, if the user works for A, then it is allowed, unless she also works for B, 
in which case it is denied. The two rules are combined using a deny-overrides 
combination operator. The first rule would not be applicable to request r^ and 
hence the request would be allowed. The first rule would be applicable to the 
remaining requests. Therefore, the evaluation of ri would return allow, while the 
evaluation of request r2 would return deny. 

Note that if the user is able to suppress the element (employer, i?) in r2, 
then the resulting request would be allowed. We call such a situation a partial 
attribute hiding attack, where, by hiding some of her attributes, a user is able 
to obtain a more favorable authorization decision. A second possibility is for the 
user to suppress all the employer attributes. Hence, we might wish to insist that 
if the resource is confidential, then the request must contain information about 
the employer(s) of the requesting user, otherwise the evaluation of the request 
should fail. In particular, r^ must not be allowed, returning either deny or some 
appropriate evaluation-error decision. 

We now describe PTaCL, which provides mechanisms to tackle the issues 
raised by this simple example, in particular by considering attribute requests in- 



stead of subject-object-action requests; by distinguishing between optional and 
mandatory attributes; and by stating two properties of monotonicity, thus al- 
lowing the detection of policies vulnerable to partial attribute hiding attacks. 



3 Targets 

We first define a syntax for targets. Then, in Section |3.1[ we will define how 
to evaluate a target with respect to a request. We define three types of atomic 
target: 

— nullx is a target; 

— n is a target, where n is an attribute name; 

— (n, V, /) is a target, where n is an attribute name, v is an attribute value 
and / is a binary predicate. 

The most usual predicate is likely to be a test for (string) equality, but other 
predicates, such as ^, <, ^ and >, are possible. For ease of exposition, we assume 
throughout that all attributes are of type string and that / is string equality; 
henceforth we omit / from the definition of an atomic target. 

We build more complex targets by defining two binary target operators, 
andT and orx, and two unary target operators, opt-p and notx- Let t, ti and t2 
be targets. Then the following terms are also targets: 

optrp notx t, (ti andx ^2) and (iiorTi2)- 

The operators optx and notx bind more tightly than andx and orx: 
optrpi andx t', for example, is interpreted as (optrpi) andx t' , rather than 



optx(t andx t'). As we will see in Section 3.f the semantics of orx and andx are 
provided by associative, commutative binary operators on Decx, so we can (and 
will) omit brackets from expressions of the form {ti orx (^2 orx • . • orx tk)) and 
{ti andx (^2 andx • . • andx ^fe))- 

In Section [4j we will define similar operators for policies and use a subscript 
P to distinguish them from target operators. When no ambiguity can occur we 
will omit the subscripts T and P. 



3.1 Evaluation 

A target is evaluated with respect to a request, represented as a set of name- 
value pairs (as described in Section [2]) . Informally, a request is said to "match" 
an atomic target if the name of one of the attribute pairs in the request is the 
same as the name defined in the atomic target and the predicate / evaluated at 
V and the corresponding value in the request is true. If no such pair exists in the 
request, then the request does not match the target. 

The "universal" target null is matched by all requests; the target n is matched 
by all requests that include an attribute pair (n, u) for any value v; the target 
{n,v) is matched by any request that includes the specific attribute pair {n,v). 
The target employer, for example, is matched by requests ri and r2 defined in 
Section [2] but not by the requests rs and r4. 
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Fig. 1. Binary and unary operators on the target decision set {1t,0t,-Lt} 



In addition, we may wish to distinguish the case where the request does 
not include the attribute name at all from the case where the attribute name 
was found, but with a value that does not match. Consider the atomic target 
(employer, B): then request ri has a matching attribute name (employer), but 
A ^ B; in contrast, requests and r4 do not include any matching attribute. 

Informally, a request must match both ti and t2 for it to match target (ti and 
t2), while a request is only required to match one of ti and t2 for it to match 
target {ti ort2). By default, a request is required to match a target t; we can 
relax this requirement, while retaining the possibility of matching t, by writing 
opti. 

More formally, we define the set of target evaluation decisions Decx to be 
{It, Ot, J-t} 1^ where J-t denotes that a request does not include the attribute 
name. It denotes that a request matches an atomic target, and Ot denotes that 
a request includes the attribute name but the predicate doesn't hold. 

We define the binary operators n, U, n and U on {It, Ot, J-t} in Fig-[l] These 
operators correspond to the weak and strong Kleene operators [TD] , respectively. 
We also define two unary operators ^ and ^ in Fig. [T] Finally, we define the 
total order It > Ot > J-t on DecT and let LJ denote the least upper bound 
operator on this ordered set. 

Given a request q, we write |t]T('?) to denote the evaluation of t with respect 
to q. That is, P]t('z) G DecT. As for target operators, we will omit the subscript 
T where no ambiguity can arise. First, we define, for all requests q and for all 
attributes n and all values v, 

[nulll(q) = It and M(0) = l(n,«)l(0) = ±t. 

We then define the evaluation of targets n and (n, v) recursively. 



lnl{{in',v')}Uq) 



It if n = n' 
|n]((7) otherwise. 



^ We will use analogous notation for decisions, where Ip will denote an "allow" decision 
and Op will denote a "deny" decision. 



{It ii n — n' , V — v' 

OTUl{n,v)}{q) ifn^n\v^v' 
l{n,v)l{q) otherwise. 

Note that, for all q, {nKq) is either It or _Lt- In evaluating we compare 

each element of the request with the atomic target and do one of the following: 
we return It if a match is found; if the attribute name matches but the predi- 
cate doesn't hold then we record the fact that the attribute name matched and 
continue processing; otherwise, we simply continue processing. 

Since U is a supremum operator, it is commutative and associative and hence 
can be applied to any subset of DecT without ambiguity. Hence, for a non-empty 
request q = {{ni, vi), . . . (n^, w^)}, it is easy to see that we have 

lnjiq)^U{lnmn^,v,)})■.l^^^k}■, 

= U z;,)}) : 1 ^ i ^ k} . 

In other words, we can evaluate the applicability of a request with respect to 
a target by splitting the request into single name-value pairs and evaluating 
each of these requests separately. This, in turn, suggests that the evaluation of 
requests can be parallelized, with different TEFs specialized for the evaluation 
of requests for particular attribute names. 

We then define the semantics of nott, opti, ti and t2 and t2 ori2 as follows: 

Inot tj{q) = ^Mq) liiandy(g) = M(q)nM(g) 
loptil(g) = ^Miq) Ih orhm = Ihjiq) U M{q) 

Here we see that opt "weakens" the target t by converting a _Lt deci- 
sion (missing attribute) into a Ot decision (attribute not matched). The target 
opt role, for example, evaluates to It if a request contains a role attribute pair 
and evaluates to Ot (rather than _Lt) if no such pair is present in the request. 

It is important to note that the semantics for the and operator are provided 
by weak conjunction n, not by n. The point here is that a target is specified 
as part of a policy and it should not be possible to force target evaluation to 
return Ot when the target is a conjunction and at least one of the conjuncts is 
mandatory. (Had we combined targets using n, if were to evaluate to Ot and 
^2 were to evaluate to _Lt, then ti □ t2 would evaluate to Ot, not the desired 

±T.) 



3.2 Interface targets 

An atomic target of the form (n, v) requires that a particular attribute value 
must appear in a request (to obtain a match). Such targets are little different 
conceptually from those defined in XACML 2.0 and other authorization lan- 
guages and are, therefore, of limited novelty or interest here|^ 

* Targets in XACML 2.0 only consider subjects, objects and actions; targets in the 
draft XACML 3.0 do consider other types of attributes. 



In contrast, targets of the form n, have not previously been seen in the 
literature on authorization languages (to the best of our knowledge). A target 
of the form n can be used to define a target that enforces a "request interface" : 
a target of the form 

opt(ni and n2 and . . . and rife), 

for example, only matches a request that contains particular named attributes 
(corresponding to ni, . . . , n^); the evaluation of a request that doesn't contain all 
the required attributes will evaluate to Ox (because of the opt). In this way, we 
can construct a target that "guards" conventional subject-object-action policies 
and others that can respond to requests containing other types of attributes. 

More complex "mixed" interfaces can also be constructed. An access control 
list is a type of access control data structure that is widely used in operating 
systems. The target for a policy used to represent an access control list for object 
test.txt would have the form 

opt((object, test.txt) and subject and action), 

so that only requests that specify the desired object as well as including some 
subject and action would match. 

3.3 Target equivalence 

We say that two targets ti and t2 are equivalent if, for all requests q, [fi](g) = 
|[i2l((!'), and write ftij = ^2] to denote that ti and t2 are equivalent. We note 
the following properties of our target operators. 

Proposition 1 For all targets t and t' , we have 

|not(not t)l = Itj Iopt(t and t')j = |(opt t) and (opt t')l 
|opt(opt t)j = |opt tj |opt(t or t')j = |(opt t) or (opt t')j 

Proof All the above results can be established by considering suitable "truth" 
tables. 

Note, however, that 

Iopt(nott)l ^ Inot(optt)l 
Inot(ti and tj)! I(notii) or (notia)! 
|[not(ti ori2)l ^ [(notti) and (notta)! 

because we use weak conjunction and strong disjunction to provide the semantics 
for and and or respectively. 
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(a) Over the set {3, 2, 1} (b) Over the set {It, -Lt, Ot} 

Fig. 2. Jobe's 3- valued logic 

3.4 On functional completeness 

By way of motivation, we first observe that it miglit be useful to be able to define 
"conditional" interface targets, where the presence of one attribute in a request 
requires the presence of some other attribute. Suppose, for example, we have 
two attribute names rii and 71,2. If a request doesn't contain attribute ni then 
the evaluation of the target should be Ot- If, however, a request does contain ni 
then it must contain n2. In other words, we have the following "match table", 
where the row headers indicate the values taken by the evaluation of ni and the 
column headers indicate the values taken by 722. 





Ix -Lt 


It 






Ot Ot 



By inspection of the match tables in Fig. [T] we see that the above table could 
be represented by the target ~ a; fi y, where x and y denote the evaluation of tt-i 
and 712, respectively. However, the semantics of and are given by the operator 
n. Hence, it would be useful to demonstrate that our chosen target operators 
opt, not, or and and are functionally complete. In particular, we would prefer to 
define the interface target described above in terms of our existing operators, 
rather than having to introduce another type of target conjunction. 

We now prove that for all n and any function / : Ded^ DecT, / can be 
constructed using the constants It, Ot and J-t and the operators opt, not and or. 
We obtain this property by proving that the three-valued logic expressed over 
the set {Ot,1t,-Lt} and defined by the operators U, ^ and ~ is functionally 
complete, re-using a result of Jobe f5], stated below. 

Theorem 1 (Jobe 1962) The three-valued logic E expressed over the set 
{1,2,3} and defined by the operators •,£'1 and E2, given in Fig.^^a), is func- 
tionally complete. 

Corollary 2 The three-valued logic expressed over the set {Ot, It, J-t} cind de- 
fined by the operators Ci, ^ and ^ is functionally complete. 

Proof We first define the operator □ from U and ^: for any Xi,X2 G Dbct, 

{X, n X2) = -(-Xi u ^X2f\ 

^ Note that we also have the expected equivalence {Xi U X2) = —•{-^Xi n —•X2) 



We can clearly see from Fig. [2|Jb) , that the operator f] is identical to • and 
^ is identical to Ei. Therefore, we only need to define a unary operator that 
swaps the values of Ot and _Lt while leaving It unchanged. We write ^ to 
denote such an operator. The table below demonstrates that is equivalent 

to (xu_LT)n(-(xu^x)). 
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We can therefore conclude that the logic defined over the set {Ot, 1t,-Lt} 
by the operators U, ^ and ^ is functionally complete. 

For instance, the operator and can be built directly from or and not, since we 
can define the operator n from U and ^. Indeed, for any x,y ^ Dect, we have 
the following equivalences; 

xr\y = {xf\y)\A {{xf\ -^x) U (y □ ^j/)) 
X U y = (x U y) fi ((x U ^x) n (y U ^y)) 

We also have xiAy = (a; U (~ y) ) fi ( a;) U y) , where U is the supremum operator 
used to define the evaluation of an atomic target. 



4 Policies 

PTaCL policies are defined inductively. Let d E {lp,Op}, and let p, pi and P2 
be policies. Then 

— d is a policy; 

— notpp - the negation of policy p - is a policy, which returns Ip if p returns 
Op and vice versa; 

— dbdpp - the deny-by- default of policy p ~ is a policy, which returns Ip if p 
returns Ip and returns Op otherwise; 

— Pi andp p2 - the conjunction of two policies pi and p2 ~ is a policy; 

— {t,p) - the restriction of policy p to a target t - is a policy. 



We discuss policy evaluation in detail in Section [4~T 

A policy tree is a convenient way of visualizing a policy and can be constructed 
recursively from a policy. The policy d is represented as a tree comprising a 
single node. The policy pi andp p2 is represented as a tree comprising a root 
node labelled andp and two child sub-trees representing pi and p2- Policies of 
the form (t,p), dbdpp and notpp are represented as trees comprising a root node 
labelled i, dbdp and notp, respectively, a single child sub-tree representing p. An 
illustrative policy tree representing the policy 

dbdp(t5, notp(i3, {ti, Ip) andp (t2. Op)) andp {t^, Ip)) 



is shown in Fig. 3(a) To save space, we have "absorbed" the nodes labelled andp 



into their respective parents {ts and t^). 



4.1 Policy evaluation 



The evaluation of a policy with respect to a request q returns _Lp if the policy is 
not applicable to the request: that is, the evaluation of the policy's target with 
respect to q returned Ot- However, it may be the case that the evaluation of a 
target returns neither It nor Ot, instead returning _Lt- The possibility of target 
evaluation failing is considered in XACML [12^ and in the work of Li et al. [11] 
and of Crampton and Huth [6 . The methods used to handle such failures assume 
that target evaluation failures arise because of unexpected failures in hardware, 
software or network connectivity and, accordingly, make a best effort to construct 
a conclusive decision for the request. 

Our target language is expressly designed to support flexible request formats 
for open environments. As a result, our language explicitly includes the possi- 
bility that target evaluation may not be possible (if, for example, attributes are 
missing). Hence, target evaluation may fail, not because of "benign" failures, but 
because a user may withhold attributes in an attempt to force an error in target 
evaluation and thereby circumvent policy evaluation. Therefore, we must ensure 
that no advantage is gained by a malicious user who deliberately suppresses 
information when making an access request]^ 

Our approach is to consider all possible decisions that might have arisen 
had target evaluation not failed. In other words, policy evaluation may return a 
set of decisions. We shall see that imposing appropriate restrictions on targets 
and using a "conservative" method of deriving a single decision from a set of 
decisions, will enable us to guarantee that a malicious user obtains no advantage 
by withholding attribute information. 

We recall the operators ^, ^ and f] on DecT (as shown in Fig.[l]) and define 
the same operators on Decp = {lp,Op,_Lp}. We extend these unary operators 
to X C Deep, writing to denote the set {^x : x £ X} and ^ X to denote 
the set {~x : x G X}; and we extend n on Deep to sets X,Y C Deep, writing 
XflY to denote the set {x f] y: x e X,y e Y}. 

Informally, the evaluation of targeted policy (i,p) for a request q proceeds in 
the following way. 

1. If i evaluates to It, we then inductively evaluate p (see below) 

2. If t evaluates to Ot, we return {-Lp} 

3. Otherwise, we evaluate p and take the union of the resulting set of decisions 
with {-Lpf] 



We also note the possibility that the user may not wish to divulge certain attributes 
when making an application request. 

In other words, the evaluation of p in this case considers the decisions that would 
have been returned if the request had been applicable and if the request had not 
been applicable. 



We write [[p]p((z) to denote the evaluation of poUcy p with respect to a request 
g, where 



I4piq)=d; 

Inotpplp(<z) = -(Wp(g)); 
Idbdpplp(g)=^(blp(g)) 

andp P2)h{q) = bilp(9) n b2lp(g); 



mp)lp{q) 



,lp(g) if Mt(<?) - It, 

{±P} if MT(g) = Ot, 

{_Lp} U |p]p(q') otherwise. 



Consider the pohcy depicted in Fig. 3(a) and suppose that |ii]((7) = 1*41(5) = 
PsK?) = It, 1*2! (9) — Ot and pa] = ±t- The evaluation of this policy is shown 
in Fig. 3(c) Note that the evaluation of the sub-tree with root ^3 considers the 
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Fig. 3. Evaluating a PTaCL policy 



union of two sets of decisions because paK*?) — J-t- Note also that the strong 
conjunction □ has the effect of preferring the _Lp decision to the lp decision. 
For those familiar with previous related work, this may seem an unusual way 
in which to combine policy decisions. We discuss this in more detail in the next 
section and, in Section [4. 3[ we will discuss ways in which more familiar decision- 
combining operators can be defined. Finally, note that the policy does evaluate 
to a single decision (Op) for this request, although there is no reason in general 
for this to occur. However, it is easy to establish the following result. 

Lemma 3 Let p be a policy whose policy tree contains targets ti, . . . ,tk and let 
q be a request. If |ii]((/) 7^ J-t for all i, then Ipjiq) = {x} for some x G Deep. 



In other words, if the apphcability of ah targets referenced by a pohcy can 
be determined for a request q, our evaluation semantics will return a unique 
authorization decision. The proof is a straightforward induction on the depth of 
the policy tree. 

Finally, we note that the functional completeness for the target language also 
holds for our policy language, because optx and dbdp have identical properties, as 
do notx and notp. However, it is also important to realize that the interpretation 
of J-T and _Lp are quite different: the fornic'r indicatc's that the request supplied 
insufficient information to evaluate target applicability, whereas _Lp indicates 
that a policy is irrelevant to the evaluation of a request. Henceforth, we will 
omit the subscript from |-]p and the PTL operators, although, for clarity, we 
will retain the subscripts on decisions. 

4.2 On the non-monotonicity of targets 

The language we use for targets and the way in which targets are evaluated 
means that, for some target t, there may exist requests q and q' such that q' C q, 
— Ot and lt}{q) — It- This feature of the language means that withhold- 
ing attributes may provide some advantage to a malicious user: if we have a 
policy p = {t,p') such that = Op, and = It, then = Op; if, 

however, \t\{q) — Ot, then \p\{q) = -Lp. In other words, it might be possible 
for a malicious user to turn a Op decision into a _Lp decision by suppressing 
certain attributes. For brevity, we refer to this as the non-monotonicity of tar- 
gets. Hence, we might reasonably regard _Lp as a potentially dangerous policy 
decision. (This view of _Lp is quite different from the interpretation used by 
other policy languages and algebras.) It is this view that informs our use of n to 
combine policy decisions, which means that _Lp fi lp is defined to be _Lp rather 
than lp. 

Similarly, a user can force a target to evaluate to _Lt (rather than Ot or It) 
by withholding attributes. It is for this reason, that policy evaluation considers 
the possibility that a target might have been matched or not matched when 
target evaluation returns _Lt- 

Following from the above discussion, we would like to prove a result of the 
form: Letp he a policy whose policy tree contains targets t\,...,tk and let q he a 
request. Then for any q' C q, \p\{q) C |[p](g'). Informally, this result states that 
if a request contains less information, then the result of evaluating the policy is 
more uncertain. Then the authorization decision point can have a decision-set 
"resolution strategy" that returns a single final decision. Such a strategy should 
be "conservative" in the sense that the larger decision sets should be treated 
with more caution. The obvious strategy of this nature is: for X C Decp, we 
return lp if X = {lp} and Op otherwise. 

However, it is easy to see that the above result does not hold, because of 
the functional completeness of our target language. In particular, we can create 
an operator such that _Lt ® J-t = It and It ® J-t = J-t- Now consider the 
target t = {ni,v\) ® (n2, 1^2), and the requests qi = {{n\,vi)} and 92 = {}• Then 

|[il(gi) = lT®-LT = -LT and pKgs) = -Lt ® -Lt = It- 



Now consider the policy p = {t, Ip): we have = {-Lp, Ip} and |p]((72) = 

{Ip}, providing a counter-example to the desired result. In other words, there 
are good reasons to restrict our target language so that only "well-behaved" 
targets can be defined. Specifically, we would like to restrict our target language 
so that all targets have the following property: 

Definition 4 A target t is monotonic if for all requests q and for every q' C q, 

M(g')e{±T,W(g)}. 

Then we have the following result (the proof is given in Appendix [A] and has 
been encoded in the proof assistant Isabelle/IsaiQ. 

Theorem 5 Let p be a policy whose policy tree contains monotonic targets 
ti,. . . ,tk and let q be a request. Then for any q' C q, Ipliq) C 

The obvious questions to ask now are: Which of our target operators are 
monotonic? And does composition of monotonic target operators preserve mono- 
tonicity? 

We say that an operator is monotonic if, given monotonic targets as inputs, it 
returns a monotonic target. We prove in appendix [A| that the operators not, and 
and or are monotonic, as well as the operators corresponding to f) and U. How- 
ever, the operator opt is not monotonic, since it can transform a _Lt into a 
Ot- 

Unfortunately (and somewhat unexpectedly), an atomic target is not, in 
general, monotonic. To see this, note that a request can contain several pairs 
with the same attribute name. (A request might, for example, enumerate all the 
roles with which the requester is associated.) Removing one occurrence from this 
set of pairs can change the evaluation of the request from It to Ot- This situation 
corresponds to a partial hiding of attribute values: that is, the ability for a user or 
an attribute server to remove only some values for a given attribute. In practice, 
such a situation is quite hard to detect and to prevent. However, let us assume 
that an attribute server works in an "all-or-nothing mode": that is, either it 
returns all the values for a given attribute, or none. With this assumption, for 
two requests q and q' such that q' ^ q and for any attribute name n such that 
{n,v) G q' and {n,v') g g, then {n,v') G q' . With such an assumption, it is easy 
to see that any atomic target is monotonic, and it follows that any target built 
using the operators and, or and not is monotonic. 

Such an assumption might not always hold, in particular when there is little 
control over the attribute servers. Therefore, we now consider an alternative, 
weaker notion of monotonicity, defined below. 

Definition 6 A target t is weakly monotonic if for all requests q and for every 
q' Q q, ¥l{q') ^ Itliq), where we define _Lt ^ Ot ^ It- 

The operators ^,n,U and U preserve the weak monotonicity, as proven in 
Appendix (bI but the operators ^ and □ do not. Moreover, since any atomic 
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target is clearly weakly monotonia, any target built using any combination from 
the operators ^, n, U and U is also weakly monotonic. Although we cannot prove 
a result as strong as Theorem [s] we can prove the following result (the proof of 
which can be found in Appendix [b|) . 

Theorem 7 Let p be a policy whose policy tree contains weakly monotonic tar- 
gets ti, . . . ,tk and let q he a request. 

1. If p is constructed from the operators not and and, then for any q' C q, if 
IpW) = {d}, with d e {lp,Op}, then Mil) - MW)- 

2. If p is constructed from the operators dbd and and, then for any q' C if 
bl(9') = {lp}, then Miq) = {^p}- 

One consequence of Theorem [7] is that if a partial request is allowed, then 
the full request would have been allowed too, and therefore an attacker has 
no advantage in hiding some attribute values. However, this result requires a 
"conservative" resolution strategy: that is, request q is only allowed if and only 
if bl(g) = {lp}. 

4.3 Decision operators 

We now discuss other ways in which decisions from sub-policies might be com- 
bined. Following Crampton and Huth [6j, we restrict attention to idempotent 
and well-behaved decision operators. 

Definition 8 Let : Deep x Deep — > Deep be a decision operator. 

— If X ® X — X for all x e Deep, then we say © is idempotent. 

— If X (B -Lp = X = _Lp © x for all x G Deep, then we say (B is a U-operator. 

— If X® _Lp = _Lp = _Lp ® X for all x £ Deep, then we say ® is an Pl-operator. 

— We say ® is well-behaved if it is either a U- or an H-operator. 

Informally, a U-operator ignores policies that evaluate to _Lp by returning a 
conclusive decision (that is, a decision that belongs to {lp. Op}) if either operand 
returns a conclusive decision. XACML, for example, assumes that all operators 
are U-operators. In contrast, a H-operator only returns a conclusive decision if 
both arguments are conclusive decisions. An operator of this nature is used by 
Bonatti et al. in their policy algebra [3]. 

Intuitively, it seems reasonable to assume that a policy decision operator is 
idempotent: if two policies return the same decision d, then we would expect 
that the composition of those policies would also return d. An idempotent, well- 
behaved decision operator is uniquely defined by the choices of a; © _Lp, lp © Op 
and Op © lp: the remaining values are fixed because the operator is idempotent 
and well-behaved (as shown in Fig. |4] for an idempotent U-operator ©). 

If we assume that © is commutative, then there are only three choices for an 
idempotent U-operator (and three choices for an idempotent H-operator). And 
if we assume that lp © Op G {lp,Op}, then there are only two choices for a 
commutative, idempotent U-operator; both these operators are shown in Fig. |4j 
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Fig. 4. Decision tables for idempotent U-operators on {lp,Op,-Lp} 



labeled as andy and oru- Analogous operators andn and orp can be defined by 
making the obvious adjustments to the bottom row and rightmost column of the 
tables for andy and or^, respectively. 

The operators andy and andn £^re rather similar to logical conjunction, while 
oru and orn are rather similar to logical disjunction, respectively. Our deci- 
sion operators play a similar role to the conflict resolution strategies or policy- 
combining algorithms used in policy algebras and XACML. Such strategies are 
used to resolve discrepancies in the results returned by different sub-policies. In 
particular, andy has the same effect as the "deny-overrides" conflict resolution 
strategy: namely, if one sub-policy returns Op, then the combined decision is Op. 
Similarly, ory has the same effect as the "allow-overrides" strategy. 

The most widely used non-commutative conflict resolution strategy is "first- 
applicable", which we denote by l>. The operator \> is defined in Fig. |4]^d): 
note, in particular, lp [> Op — lp and Op > lp = Opj^ The first-applicable 
operator is commonly used in firewall rulesets as well as in policy algebras and 
XACML. The other idempotent, well-behaved, non-commutative operator such 
that lp © Op e {lp,Op} and Op © lp G {lp,Op} is what might be called "last- 
apphcable", denoted by <1, where x < y = y ii y € {lp,Op} and is equal to x 
otherwise. This operator does not appear to be widely supported or used. 

We now show how to define the operators orn, andn, ory, andy and \> from 
the PTL operators not, dbd and and. Since the logic ({lp. Op, -Lp} , not, dbd, and) 
is functionally complete, we can directly reuse the definitions of the operators 
given in Fig.jl] Clearly, orn and andn are directly given by U and H, respectively. 
Moreover, the operator ory corresponds to the supremum operator over the total 



order lp > Op > -Lp, so we can re-use the operator U defined in Section 3.4 The 
operator andy is defined as the double negation of the operator ory: 

X andy y = not((not x) ory (not y)) 

In order to define the operator [>, we first introduce the operator abd 
( "allow- by-dcfault"), which transforms -Lp into lp, and is defined by abd a; = 
not(dbd(not a;)). The definition of \> is then given by: 

x\> y = (abd(x U (not a;))) □ [x ory y) 



® Note that a first-applicable n-operator is vacuous, as it would be equivalent to a 
unary, identity operator. 



Finally, x<\y is equivalent to yt>x. Henceforth, we will use the operators defined 
above as syntactic sugar. Notice that our definitions of or^, and^ and O all require 
the three PTL operators for their construction. Hence, a policy containing the 
standard XACML operators does not satisfy the requirements of Theorem [Tj so 
we need to rely on the all-or-nothing assumption. 

Finally, we note that the operators and, andy and andn can be regarded as 
defining a greatest lower bound operator for suitable choices of ordering on Deep; 
similarly or^ and orp define least upper bound operators. These orderings are 
summarized in Table [TJ 



Operator 


Ordering 


and 


Op < _Lp < lp 


andu 


Op < lp < _Lp 


andn 


-Lp < Op < lp 


oru 


-Lp < Op < lp 


orn 


Op < lp < -Lp 



Table 1. Decision operators and orderings on Deep 



The fact that each of the orderings is a total order means that and, andy and 
andn take the minimum of their operands, while cry and orn take the maximum 
of their operands. This, in turn, means that all four operators can be extended to 
n-ary operators (for any natural number n > 1). We examine the consequences 
of this in the next section. 



as 



4.4 Policy sets and policy lists 

Consider the policy tree depicted in Figure |5(a) This policy can be expressed 

<, (i,(<i,lp)oru (t2,0p))oru {tsAp)) 

Given that the target and operator match in the two non-leaf nodes and that 
ory is commutative, we could represent the policy as 

(t,oru,{(ii,lp),(i2,0p),(t3,lp)}), 

as illustrated in Figure [5(b)[ 

Clearly, we can extend this argument to policy trees that combine n subtrees 
with equivalent targets and use the same commutative operator. Accordingly, 
we extend our policy syntax to include policies of the form (i, ©, P), where t is 
a target, © is a commutative operator and P is a set of policies. Then, for all 
fc ^ 2, for all policies pi,. . . ,pk and all operators ® e {and, andy, or^, andn, orn} 
we define 



I(null,©,{pi,...,pfc})](g) = {di®---®dk:d^e I^Kg)}, 



(t,oru) 




(tl,lp) (t2,0p) (tl,lp) (t2,0p) (t3,lp) 

(a) Binary operators (b) n-ary operators 

Fig. 5. From binary to n-ary operators 

Now we recall that and, andy and andp can be interpreted as greatest lower 
bound operators defined over suitable total orderings on {Ip, Op, J-p} (as shown 
in Table [T]). Similarly, cry and orn are least upper bound operators. Hence, the 
evaluation oi di (3 ■ ■ ■ (3 dk is equivalent to computing the maximum value in the 
set {di, . . . , dfe} in the case of disjunctive operators and the minimum value in 
the case of conjunctive operators. Consider, for example, 

{di andu • • • andy dk : di e . 

Now we know that xi andy • • • andy is the minimum value in {xi, . . . , Xk} 
with respect to the order Op < Ip < _Lp. Hence, the maximum value that 
di andy • • • andy dk can take is dmax, where 

dmax = min{max(|pi](g)), . . . , max(|pi.](g))} . 

Similarly, the minimum value that di andy • • • andy dk can take is dmin, where 

rfmin = min{min(Ipi](g)), . . . , min(|pfc](g))} . 

Now if dniin — rfmax, WC havC 

{di andy • • • andy dk ■ di e IkK?)} = {dmin} ; 

otherwise, {c?i andy • • • andy dk '■ di IPiliQ)} is a set containing more than one 
decision and the conservative approach requires us to return Op . If, for example, 
IpiKq) = {Op, Ip}, lP2l{q) = {Ip} and [psK?) = {Op,_Lp}, then d„,ax = Ip and 

C^min = Op. 

We can derive analogous methods for computing 
{di (B ■ ■ ■ (B dk ■ di e IPiliq)}, for ® S {andn, ory , orn}. Hence, we can compute 
{di (B ■ ■ ■ (B dk di € lPi}{q)} in hnear time for © £ {and, andy, andp, ory, orp}. 

Note, however, that we cannot apply the same re-writing technique to the 
pohcy 

(t, (t,(ii,lp)C>(t2,0p)) [>(t3,lp)) 

because [> is not commutative (so the order in which sub-policies are evaluated 
is significant). Hence, we need to interpret the policy as 



(i,>,[(tl,lp),(i2,0p),(i3,lp)]), 



where [pi, . . . ^pk] is to be understood as a list of sub-policies that must be 
evaluated in the specified order. Moreover, because > has no interpretation as a 
maximum or minimum operator, we have no quick way of evaluating 

{di t> ■ ■ ■ [>dk : di £ Ipiliq)} 

because we have to evaluate each possible combination of di, . . . , d^. To summa- 
rize: 

— We can group a set or list of policies together under a single target and 
decision operator. 

— All commutative operators can use either set or list processing; non- 
commutative operators can only use list processing. 

— Policy sets can be evaluated in any order, whereas policy lists must be pro- 
cessed in the order specified in the list. 

— Most importantly, policy sets can be evaluated quickly, unlike policy lists 
(for non-commutative operators). 



4.5 Policy equivalence 

We say two policies pi andp2 are equivalent if for all requests g, IpiK?) = [[P2l('z)- 
We write = |p2l if Pi and p2 are equivalent. 

Note that {t, Ip) returns Ip for all requests that match t, so not(t, Ip) returns 
false for all requests that match t. In other words, the policy (t, Op) is equivalent 
to the policy not(t, Ip), which means that the policies of the form {t, Op) are not 
required (although they may be useful as syntactic sugar). 

Proposition 9 For all policies pi and p2, 

Idbd(pi andp2)l = I(dbdpi) and (dbdpa)!, 
|not(pi andu ^2)! = I(notpi) cry (notp2)l, 

|not(pi oru P2I = Knotpi) andy (notp2)l, 
|not(pi andnP2)l = [[(notpi) orp (notp2)l, 

|not(pi orn P2I I(notpi) andp (notp2)l- 

Proof The proofs follow by inspection of the appropriate decision tables. 



5 Related work 

It is important to note that PTaCL is neither intended to fix XACML nor to 
provide formal semantics for XACML policy evaluation. Rather, PTaCL is a lan- 
guage that seeks to provide rigorous, alternative solutions to the same problems 
that motivated the development of XACML. Our work is also influenced by the 
work of Li et al. [TT] and of Crampton and Huth [5] on using a set of decisions, 
rather than a single decision, to define the result of policy evaluation. 

Although there is a substantial body of work on policy specifica- 
tion |l|4)5|12fT6] . this prior work assumes a very restricted format for access 



requests and targets. To the best of our knowledge, there is no previous work on 
a formal language for target specification and evaluation, let alone the consider- 
ation of missing attributes names. Both the ratified standard XACML 2.0 [13] 
and the draft XACML 3.0 |14], acknowledge that attributes may be missing from 
a request. However, the treatment of target evaluation in such circumstances is, 
like much of the XACML standard, rather informal. Moreover, the XACML tar- 
get syntax is unnecessarily complicated and does not support interface targets. 
Finally, the XACML target syntax only provides operators that are equivalent 
to the strong conjunction and strong disjunction (in the 3- value Kleene logic), 
thereby limiting the expressive power of XACML. On the other hand, the func- 
tional completeness of PTL means that any XACML target can be represented 
in PTL. 

The work on policy algebras varies in the operators that are supported, the 
set of decisions that can arise as a result of policy evaluation, and the extent 
to which policy evaluation can cope with failures in target evaluation. Ni et 
at, for example, provide a functional complete policy algebra 12], where policy 
evaluation returns a single decision from the set {lp,Op,_Lp}. The functional 
completeness of PCL means that we can express any operators that we might 
wish to. In particular, we can express all XACML policy-combining algorithms. 
Structurally, our atomic policies correspond to rules in XACML, while our policy 
trees correspond to policies and policy sets. Crampton and Huth [B^ extend 
the work of Li et al. on policy evaluation in the presence of target evaluation 
failure where policy evaluation returns a set of decisions. Our treatment 
of policy evaluation is rather similar to this earlier work, although the way in 
which we resolve a set of decisions to a single decision that is enforced by the 
AEF is completely different, due to the suspicion with which we choose to treat 
the _Lp decision. 

An important contribution of this paper is the recognition that providing sup- 
port for attribute-based access control and greater freedom for request formats 
leads to the potential for attribute hiding by malicious users. By manipulating 
requests in this way, it may be possible to circumvent the expected or intended 
policy semantics. Existing work that supports attribute-based access control, 
such as XACML 3.0 and that of Rao et al. [T5], does not consider such pos- 
sibilities and hence may be vulnerable to "attribute-hiding attacks". Consider, 
for example, the PTL policy p = (Ip and^ ((n,w),Op)) - which corresponds to 
an XACML policy with two rules combined using the deny-overrides operator - 
and two requests q — {(n, w), {n,v')} and q' — {{n,v')}. Then |p](<7) = Op while 
IpK?') = Ip- that is, by hiding some information, a more favorable answer is 
obtained. Theorem [7] suggests that such behavior is to be expected because we 
require all three PTL operators to represent andu. 

6 Concluding remarks 

Attribute-based access control, rather than the traditional identity-based access 
control that is deployed extensively in closed systems, is likely to become in- 



creasingly important in loosely coupled and open computing environments. This 
paper introduces PTaCL, an expressive language for the definition of attribute- 
based authorization policies. PTaCL can represent all commonly used policy 
composition operators (indeed it can represent any desired operator) and, to the 
best of our knowledge, PTaCL is the first language with a concise syntax for 
policy targets and a precise semantics for their evaluation. 

Nevertheless, PTaCL is rather simple syntactically, which enables us to iden- 
tify and propose sohitions to the problem of attribute hiding. Such an issue 
is problematic in the context of open and distributed systems, and is not ad- 
dressed in the literature, which define composition operators to favor conclusive 
decisions over a not-applicable decision. Having identified the problem, we pro- 
pose two approaches to address this issue, formally justifying each of them: 
either forbidding optional targets, assuming the attribute servers to work in an 
"all-or-nothing mode" and adopting a conservative evaluation; or constraining 
more strictly the definition of the targets and the definition of the policies. The 
second approach does not make any assumption of the attribute servers, but 
the standard policy composition operators can no longer be used. We propose 
other operators that are resilient to attribute hiding and differ from the standard 
ones in the way in which they handle the not-applicable decision. These "new" 
operators actually correspond to the strong conjunction and strong disjunction 
defined in the original Kleene three- valued logic. 

There are many opportunities for future work. Clearly, when the evaluation 
of a request returns more than one decision, it implies that some attributes are 
missing in the request, and PTaCL should be extended in order for the set of 
the decisions to also indicate which attributes are missing. Hence, the entity 
in charge of collecting the attributes, for instance the Context Handler in the 
XACML architecture, is able know which attributes to collect again. PCL can 
be similarly extended in order to support obligations, that can be returned in 
addition to a set of decisions. 

These extensions naturally lead to the problem of understanding and formal- 
izing the complete access control architecture, and in particular to the question 
of attribute privacy. Indeed, in practice, a reason for a missing attribute can be 
because the source responsible for providing its value considered that this value 
was too sensitive to be shared. In such a case, the evaluation of the policy, or 
part of it, needs to be delegated to the attribute source. However, the possible 
presence of multiple, sensitive and conflicting sources makes it a non trivial prob- 
lem to solve. We believe that by completely formalizing the notion of attribute 
and its treatment by the policy decision point, PTaCL paves the way to address 
the problem of attribute privacy. 
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A Monotonicity Proofs 

All the following proofs have been encoded and verified in Isabelle/Isar. The defi- 
nition of the three- valued logic and the corresponding operators can be found at 
http : //isg • rhul . ac . uk/- j ason/isabelle/logic . thy[ The definition of the 
target and policy evaluation, together with the proofs of the following lemmas, 
can be found at http://isg.rhul.ac.uk/~jason/isabelle/ptacl.thy 

Proof We prove the Theorem [5] by induction over the structure of p. 
1. If p — d, then {pjiq) — Ip](<z') — d and we can conclude. 



2. lip = notp', then lpj{q) = -(b'l(g)) and M{q') = -(b'l («'))• Moreover, by 
the inductive hypothesis, we have C it follows "■([p'K?)) C 
~'{lp'i{q')), and we can conclude. 

3. If p = dbdp', then Miq) = -^(b'l(a)) and bl(g') = -(b'K?'))- More- 
over, by the inductive hypothesis, we have Ip'K?) C it follows 
^dp'K?)) ^ "^^dp'l (</'))) ^■'^d we can conclude. 

4. If p = (pi andp2), then let X, ^ Ip.Uq), = baKg), = biK?') 
and X2 = lP2j{q'), and let us show that Xi fl C □ Indeed, by 
the inductive hypothesis, we have Xi C X'^ and X2 C and it follows 
that {xi fi X2 : xi e Xi, a;2 € ^2} C {xi fi 2:2 : xi G X( , .T2 G -'i'2}7 and we 
can conclude. 

5. If p = {t,p'), then by induction hypothesis, we have C Since 
t is assumed to be monotonic, four cases are possible. 

(a) Either = lt}{q') = Ot, and in this case Mid) = MW) = {^p}, 
and we can conclude. 

(b) Or Itl(g) = mq') = It, and in this case bK?) = b'K?) and MW) = 
Ip'liq'), and since we have b'](g) C b'Kq'), we can conclude. 

(c) Or Mq) = Itjiq') = ±t, and in this case = {±p} U b'Ka) and 
bK?') = {-Lp} U bK^Oi and we can similarly conclude. 

(d) Or miq) e {Ot,1t} and = ±t, and in this case, bK?) G 
{{_Lp} , b'K?)} and bl(?') = {-Lp} U b'!?'; and we can also conclude. □ 

Lemma 10 Given any monotonic target t, the target not t is also monotonic. 

Proof Let q, q' be two queries such that C q. Let us show that ^(liK?')) € 
{J-T, ^(1^1(9))}- Three cases are possibles. 

1. If -'(|d('?)) — It, then by definition of -•, lt\{q) = Ot. Since t is monotonic, 
we have G {_Lt,Ot}, and therefore we can conclude that -'|t]((7') G 
{±t,1t}. 

2. If -'(PK?)) = Ot, then by definition of -•, \t\{q) = It. Since t is monotonic, 
we have PK^/') G {J-t, It}, and therefore we can conclude that G 
Ut,Ot}. 

3. If -'(PK'?)) = J-T, then by definition of -•, \t\{q) = _Lt. Since t is monotonic, 
we have PKg') = J-t, and therefore we can conclude that ^I^K?') = J-t- D 

Lemma 11 Given two monotonic targets ti and t^, the target ti or t2 is also 
monotonic. 

Proof Let q,q' be two queries such that q' C q. Let us show that U 
It^W)) e {-Lt, LI p2l(g))}. Three cases are possibles. 

1. If [til((z)Up2l(g) = It, then by definition of U, {tiHq) = It or [taK?) = It- 
Since ti and t^ are monotonic, we have G {_Lt, It} or 1^21(9') S 
{J-T, It}, and therefore we can conclude that [tiK?') U p2l(Q'') S {J-t, It}- 

2. If Itiliq) G Miq) - Ot, then by definition of U. lt,}{q) = Miq) = Ot- 
Since ti and ^2 are monotonic, we have [^iKg') G {-Lt,Ot} and [f2](5') G 
{±t,Ot}, and we can conclude that lti}{q') U lt2}{q') & {-Lt,Ot}- 



3. If LJ |t2l(9) — J-T, then by definition of U, at least one target among 

{^1,^2} evaluates to _Lt while the other one evaluates either to Ot or to _Lt- 
Let us consider that |ii]((z) — J-t and p2l(9) G {J-TjOt}, the symmetrical 
case being equivalent. Since t\ and ti are monotonic, we have = 
_Lt and |i2l('?') G {-Lt,Ot}, and therefore we can conclude that U 
p2l(g') = ^T. □ 



Lemma 12 Given two monotonic targets ti and t2, the targets ti andp, t2, ti and 
t2 and ti oru t2, where andp and cry are semantically defined by the operators □ 
and U, respectively, are also monotonic. 

Proof The proofs follow directly from the definitions of fi, □ and U using U and 

□ 

B Weak Monotonicity Proofs 

Proof We prove the first case of the Theorem [7] by induction over the structure 
of p, the proof of the second case is similar. 

1. If p = d, it follows that — IpHq') and we can conclude. 

2. If p - notp', then H(q') = -([pl(g'))- From H(g') = {d}, with d G 
{Ip, Op}, we can deduce that = {^d}. Moreover, by the inductive hy- 
pothesis, we have Miq) = b'l(g'), it follows -(bKg)) = {d} = -(bl(q')), 
and we can conclude. 

3. If p = (pi and P2), then let Xi = [pil(q), X2 = [p2l(g), X[ = Ipil(g') and 
X'2 = IP2] ((?')■ Two cases are possible, depending on the value of |p](q')- 

(a) Either |p]((?') = {Ip}, and in this case, we can deduce that X[ = X2 = 
{Ip}. By the inductive hypothesis, it follows that Xi = X2 — {Ip} and 
therefore we have IpKg) — {Ip} = IpK?'); and we can conclude. 

(b) Or [[p]((?') = {Op}, and in this case, from the definition of fl, we can de- 
duce that either X[ = {Op} or X2 = {Op}. By the inductive hypothesis, 
it follows that either Xi = {Op} or X2 = {Op} and therefore we have 
IpHq) = {Op} = M (<?'): and we can conclude. □ 

4. If p = {t,p'), then from |p](9') = {rf}, with d G {lp,Op}, we have that 
PK?') = It, and since t is assumed to be weakly monotonic, we can deduce 
that = It. It follows that M{q) = Miq) and M{q') = [p'Kg'), and 
by induction hypothesis, we can conclude. 

Lemma 13 Given any weakly monotonic target t, optt is weakly monotonic. 

Proof Let q,q' be two queries such that q' C q. Let us show that "^(PK?')) ^ 
'-^([[t]((7)). Since "-^(1^1(9)) 7^ J-t, by definition of only two cases are possibles. 

1. Either ^(PK?)) = iTand we can trivially conclude. 

2. Or ^{liliq)) = Ot, then by definition of ~, |t](g) e {_Lt,0t}. Since t is 
weakly monotonic, we have ^ M(<z') and thus G {_Lt,0t}. It 
follows that = Ot, and we can conclude. □ 



Lemma 14 Given two weakly monotonic targets ti and t2, the target ti or t2 is 
also weakly monotonic. 



Proof Let q,q' be two queries such that q' C q. Let us show that ([iiK?') LI 

[i2l(g')) =^ (PiK?) LI Ii2l('z))- Three cases arc possibles. 

1. If ItiK*/) U 1^2] (?) = It, then we can trivially conclude. 

2. If Itiliq) U |t2l(g) = Ot, then by definition of U, = Ot and [tsKg) = 
Ot- Since ti and t2 arc weakly monotonic, we have |ii](<7') € {_Lt,Ot} 
and lt2j{q') G {-Lt,Ot}- By definition of U, it follows U lt2j{q') € 
{_Lt,Ot} and we can conclude. 

3. If |ii](<z) U It2l('?) = J-T, then by definition of G, at least one target among 
{^1,^2} evaluates to _Lt while the other one evaluates either to Ot or to 
J-T- Let us consider that pi] (9) = J-t and [t2l(9) S {_Lt,Ot}, the sym- 
metrical case being equivalent. Since ti and t2 are weakly monotonic, we 
have ltij{q') = _Lt and lt2j{q') S {-Lt,Ot}- By definition of U, it follows 
I^iK?') LI [t2l(9') = J-T, and we can conclude. □ 

Lemma 15 Given two weakly monotonic targets ti and t2, the target ti and t2 
is also weakly monotonic. 

Proof Let q,q' be two queries such that q' C q. Let us show that n 
p2l(g')) ^ (PiK?) n Ihliq))- Three cases are possibles. 

1. If [[ti](<7) n 1^21 (<?) = It, then we can trivially conclude. 

2. If Itijiq) n lt2j{q) = Ot, then by definition of n, either piK?) = Ot or 
1^21(0') = Ot- Since ti and t2 arc weakly monotonic, wc have either piKf/') € 
{_Lt,Ot} or [[t2l(<?') e {_Lt,Ot}- By definition of n, it follows |ti](V) n 
p2l('i'') G {-Lt,Ot} and we can conclude. 

3. If Itiliq) n p2l('?) = -Lt, then by definition of n, either piKg) = -Lt or 
1*2] (9) = J-T- Since ti and ^2 are weakly monotonic, wc have either = 
J-T or p2l(g') = J-T, and it follows n |t2l(«') = J-T, allowing us to 
conclude. □ 

Lemma 16 Given two weakly monotonic targets ti and t2, the target ti cry t2, 
where ory stands for the syntactic sugar corresponding to the operator U, is also 

weakly rn,onotonic. 

Proof Let q,q' be two queries such that q' C q. Let us show that LI 
Ihjiq')) 4 (Pil(g) LI It2l(g))- Three cases are possibles. 

1. If U 1^21(9) — It, then we can trivially conclude. 

2. If Itiliq) U p2](g) = Ot, then = |i2l(g) = Ot- Since ti and t2 are 
weakly monotonic, we have & {-Lt,Ot} and |i2l(<z') G {_Lt,Ot}- By 
definition of U, it follows [[ti](<7')U p2l(9') € {_Lt,Ot} and we can conclude. 

3. If U p2l(g) = -Lt, then by definition of U, either = -Lt or 
p2](9) = J-T- Since ti and t2 are weakly monotonic, we have either = 
_Lt or |t2l(g') = -Lt- By definition of U, it follows [tiKg') U p2l(g') = -Lt 
and we can conclude. □ 



